자바 애플릿

자바 애플릿은 1995년 썬 마이크로시스템즈가 발표한 자바 프로그래밍 언어의 핵심 기술 중 하나로 등장했다. 당시 웹은 정적인 HTML 페이지가 주를 이루었고, 동적인 콘텐츠나 상호작용적인 애플리케이션을 실행하기는 어려운 환경이었다. 자바 애플릿은 "한 번 작성하면 어디서나 실행된다"(Write Once, Run Anywhere)는 자바의 철학을 웹 브라우저로 확장하여, 웹 페이지 안에서 플랫폼 독립적인 풍부한 그래픽 사용자 인터페이스(GUI)와 복잡한 로직을 실행할 수 있게 했다. 이는 당시 경쟁 기술이었던 마이크로소프트 액티브X나 어도비 플래시와 달리 특정 운영체제에 종속되지 않는다는 점에서 큰 장점으로 부각되었다.

초기 발전은 매우 빠르게 이루어졌다. 1996년 출시된 넷스케이프 내비게이터 2.0에 자바 애플릿 지원이 포함되면서 본격적인 보급이 시작되었다. 애플릿은 교육용 시뮬레이션, 인터랙티브 게임, 실시간 차트, 복잡한 양식 입력 도구 등 다양한 분야에서 활발히 사용되었다. 웹이 단순한 문서 공간을 넘어 애플리케이션 플랫폼으로 진화할 가능성을 처음으로 제시한 기술 중 하나로 평가받는다. 자바 개발 키트(JDK) 1.1에서는 성능 개선과 함께 자바 빈즈 컴포넌트 모델과의 통합이 강화되는 등 기능이 확장되었다.

초기 웹의 동적 콘텐츠 수요를 해결하면서 자바 언어의 인기 상승에 결정적인 기여를 했으나, 플러그인 설치 필요성, 상대적으로 느린 시작 시간, 그리고 점차 강화되는 보안 제한 등이 이후 도전 과제로 부상하기 시작했다.

자바 애플릿의 쇠퇴는 2000년대 중후반부터 본격화되었다. 핵심적인 쇠퇴 요인은 보안 문제였다. 애플릿은 자바 가상 머신 내의 샌드박스에서 실행되어 시스템 자원 접근이 제한되었지만, 지속적으로 발견된 보안 취약점은 주요 위협으로 작용했다. 또한, 애플릿을 실행하려면 사용자 측에 별도의 자바 런타임 환경 설치가 필수적이었고, 버전 호환성 문제와 함께 플러그인 로딩 시간이 길어 사용자 경험을 저해했다.

더 근본적인 변화는 웹 표준 기술의 급속한 발전이었다. HTML5, CSS3, 그리고 성능이 크게 향상된 자바스크립트의 등장으로, 플러그인에 의존하지 않고도 브라우저 내에서 풍부한 멀티미디어 콘텐츠와 복잡한 애플리케이션을 구현하는 것이 가능해졌다. 애자일스나 jQuery와 같은 라이브러리와 프레임워크는 웹 개발을 더욱 쉽게 만들었다. 이에 비해 애플릿은 상대적으로 무겁고 구식의 기술로 인식되기 시작했다.

주요 웹 브라우저들의 정책 변화는 쇠퇴에 결정타를 가했다. 보안상의 위험과 유지보수 부담을 이유로 브라우저 벤더들은 점차 NPAPI와 같은 레거시 플러그인 아키텍처에 대한 지원을 줄이거나 제한하기 시작했다. 구글 크롬은 2015년 NPAPI 지원 중단을 발표했고, 모질라 파이어폭스와 마이크로소프트 엣지도 유사한 조치를 취했다. 결국 2017년에 오라클은 자바 SE 9부터 자바 애플릿 API를 폐기 예정으로 표시하고, 이후 버전에서 완전히 제거한다고 공식 발표했다.

이러한 변화로 인해, 애플릿은 기업 내부의 레거시 시스템을 제외하고는 사실상 사장되었다. 애플릿의 역할은 HTML5 캔버스와 WebGL, 그리고 점차 성숙해지는 자바스크립트 생태계가 대체했으며, 더 무거운 클라이언트 애플리케이션은 Java Web Start나 JavaFX와 같은 다른 자바 기술, 또는 일렉트론과 같은 데스크톱 애플리케이션 프레임워크로 옮겨갔다.

자바 애플릿은 웹 브라우저 내에 내장된 자바 가상 머신(JVM) 또는 별도의 자바 플러그인을 통해 실행되었습니다. 초기에는 브라우저 자체에 JVM이 통합되어 있었으나, 이후 표준화와 보안 업데이트를 위해 별도의 플러그인 형태로 제공되기도 했습니다. 애플릿의 실행 코드인 자바 바이트코드는 서버에서 다운로드되어 클라이언트의 JVM에서 해석되고 실행되었습니다.

애플릿의 핵심 보안 모델은 샌드박스(sandbox)였습니다. 이 모델은 신뢰할 수 없는 원격 코드가 로컬 시스템에 피해를 주지 못하도록 설계되었습니다. 샌드박스 내에서 실행되는 애플릿은 다음과 같은 엄격한 제한을 받았습니다.

• 로컬 파일 시스템에 대한 접근 제한 (읽기/쓰기 금지)

• 임의의 네트워크 연결 제한 (오직 호스트 서버로의 연결만 허용)

• 시스템 프로퍼티 읽기 제한

• 다른 애플릿이나 네이티브 라이브러리와의 상호작용 제한

더 높은 권한이 필요한 작업을 수행하기 위해서는 디지털 서명을 통해 서명된 애플릿을 사용자가 명시적으로 신뢰하고 승인해야 했습니다. 서명된 애플릿은 제한된 샌드박스를 벗어나 로컬 파일 접근 등의 확장 권한을 얻을 수 있었으나, 이는 주요 보안 위협 요소로 작용하기도 했습니다.

자바 애플릿의 생명주기는 웹 브라우저나 애플릿 뷰어에 의해 엄격하게 관리된다. 애플릿은 로드, 초기화, 시작, 정지, 제거의 단계를 거친다. 각 단계는 java.applet.Applet 클래스의 특정 메서드 호출에 의해 트리거되며, 개발자는 이 메서드들을 오버라이드하여 원하는 동작을 구현한다.

주요 라이프사이클 메서드는 다음과 같다.

이러한 메서드 외에도 paint(Graphics g) 메서드는 화면을 다시 그려야 할 때마다 호출된다. 이는 AWT나 Swing 컴포넌트의 표시를 담당한다. 또한 getParameter(String name) 메서드는 애플릿이 임베딩된 HTML의 <applet> 태그 내 <param> 태그로부터 값을 읽어오는 데 사용된다.

라이프사이클은 브라우저의 탐색 행동과 밀접하게 연동되어 효율적인 자원 관리를 가능하게 했다. 예를 들어, 사용자가 다른 페이지로 이동하면 stop()이 호출되어 CPU 자원을 확보하고, 다시 돌아오면 start()가 호출되어 작업을 재개한다. 이 구조는 애플릿이 웹 페이지의 일부로서 동작하는 방식을 정의하는 핵심이었다.

자바 애플릿을 개발하기 위해서는 반드시 java.applet.Applet 클래스를 상속받는 새로운 클래스를 정의해야 한다. 이 Applet 클래스는 AWT 컴포넌트 계층 구조의 일부이며, 애플릿의 기본적인 라이프사이클과 그래픽 사용자 인터페이스를 관리하는 메서드들을 제공한다.

애플릿 클래스의 기본 구조는 몇 가지 핵심 메서드를 오버라이드하여 구성된다. 가장 중요한 메서드는 init(), start(), stop(), destroy()이다. init() 메서드는 애플릿이 처음 로드될 때 한 번 호출되며, 사용자 인터페이스 컴포넌트를 초기화하고 매개변수를 로드하는 작업을 수행한다. start() 메서드는 애플릿이 화면에 표시될 때(예: 브라우저 탭으로 돌아올 때) 호출되어 애플릿을 시작하거나 애니메이션을 재개한다. 반대로 stop() 메서드는 애플릿이 화면에서 벗어날 때 호출되어 리소스를 일시 중지한다. 마지막으로 destroy() 메서드는 애플릿이 완전히 메모리에서 해제되기 전에 정리 작업을 수행한다.

다음은 가장 간단한 형태의 자바 애플릿 코드 예시이다.

```java

import java.applet.Applet;

import java.awt.Graphics;

public class HelloWorldApplet extends Applet {

@Override

public void init() {

// 초기화 코드

}

@Override

public void paint(Graphics g) {

g.drawString("Hello, World!", 50, 25);

}

}

```

이 예제에서 paint(Graphics g) 메서드는 Applet의 상위 클래스인 컨테이너로부터 상속받은 메서드로, 애플릿의 화면을 그리는 역할을 한다. 개발자는 이 메서드를 오버라이드하여 원하는 그래픽이나 텍스트를 출력한다. 애플릿의 크기는 주로 임베딩하는 HTML의 <applet> 또는 <object> 태그 내에서 width와 height 속성으로 결정된다.

자바 애플릿은 HTML 문서 내에 <applet> 태그 또는 <object> 태그를 사용하여 삽입하고 실행한다. 기본적인 임베딩 구조는 애플릿의 컴파일된 클래스 파일(.class)이 위치한 경로, 애플릿의 화면상 크기, 그리고 애플릿 코드에 전달할 선택적 매개변수를 지정하는 것이다.

초기에는 <applet> 태그가 표준이었다. 이 태그의 code 속성은 클래스 파일명을, archive 속성은 JAR 파일을 지정하며, width와 height 속성으로 애플릿의 표시 영역 크기를 픽셀 단위로 정의한다. <param> 태그를 자식 요소로 포함시켜 이름(name)과 값(value) 쌍으로 애플릿에 매개변수를 전달한다. 이후 웹 표준 강화로 인해 <object> 태그 사용이 권장되었으나, 기본적인 구성 방식은 유사하다.

매개변수는 애플릿 내부에서 getParameter() 메서드를 호출하여 읽어들인다. 이 메서드는 HTML에 정의된 name에 해당하는 value 문자열을 반환한다. 이를 통해 애플릿의 동작을 외부에서 구성할 수 있으며, 예를 들어 초기 색상, 서버 주소, 표시할 텍스트 등을 동적으로 설정하는 데 활용된다.

자바 애플릿의 보안 모델은 샌드박스 개념을 핵심으로 설계되었다. 이 모델은 신뢰할 수 없는 코드가 사용자의 시스템에 피해를 주지 못하도록 애플릿의 실행 권한을 엄격히 제한하는 환경을 제공한다. 기본적으로 서명되지 않은 애플릿은 이 샌드박스 내에서만 실행되며, 로컬 파일 시스템에 대한 접근, 다른 네트워크 호스트와의 통신, 시스템 속성 읽기 또는 실행 중인 다른 애플리케이션과의 상호작용 등이 금지된다.

주요 권한 제한 사항은 다음과 같았다.

이러한 제한을 우회하기 위해서는 애플릿에 디지털 서명을 추가하고 사용자로부터 명시적인 실행 권한을 얻어야 했다. 서명된 애플릿은 사용자 확인 후 제한된 권한 또는 완전한 권한으로 실행될 수 있었다. 그러나 이 보안 모델은 복잡한 설정, 사용자에게 혼란을 주는 권한 승인 대화상자, 그리고 서명 인증서 취소 목록 관리의 어려움 등 실용적인 문제점을 안고 있었다.

2010년대 중반부터 주요 웹 브라우저들은 보안상의 이유로 NPAPI 지원을 단계적으로 중단하기 시작했다. 이 API는 자바 애플릿을 비롯한 어도비 플래시 등의 브라우저 플러그인이 실행되기 위한 핵심 인터페이스였다. 구글 크롬은 2015년 9월 배포된 버전 45부터 NPAPI 지원을 기본적으로 비활성화했으며, 2016년 9월 버전 53부터는 완전히 제거했다.

모질라 파이어폭스는 2017년 3월 배포된 버전 52부터 NPAPI 플러그인 중 어도비 플래시를 제외한 모든 지원을 중단했고, 이후 플래시 지원도 종료했다. 마이크로소프트 엣지와 애플 사파리 역시 유사한 시기에 NPAPI 지원을 중단했다. 이로 인해 자바 애플릿은 더 이상 대부분의 모던 브라우저에서 실행될 수 없는 기술이 되었다.

브라우저 벤더들의 결정은 주로 보안 문제에 기인했다. 자바 애플릿을 포함한 NPAPI 기반 플러그인은 브라우저의 메모리 공간에 직접 접근할 수 있어 취약점이 발생할 경우 심각한 보안 위협이 될 수 있었다. 빈번한 보안 업데이트 필요성, 모바일 기기에서의 지원 부재, 그리고 HTML5, CSS3, 자바스크립트 등 오픈 웹 표준 기술의 성숙도 주요한 배경이었다.

이에 따라 오라클은 2016년 1월에 자바 개발 키트(JDK) 9부터 애플릿 API를 '사용 권고 중단' 상태로 표시했고, JDK 11(2018년 9월 릴리스)에서는 공식적으로 애플릿 관련 API를 제거했다. 이는 자바 애플릿의 공식적인 수명 종료를 의미하는 결정이었다.

Java Web Start는 자바 애플릿의 제한을 극복하기 위해 도입된 배포 기술이다. 사용자가 웹 브라우저에서 링크를 클릭하면 JNLP 파일을 통해 네트워크를 거쳐 애플리케이션을 다운로드하고 로컬 시스템에서 실행한다. 이 방식은 애플릿과 달리 독립적인 데스크톱 애플리케이션으로 작동하며, 브라우저에 종속되지 않고 풍부한 GUI와 시스템 리소스에 대한 더 넓은 접근 권한을 제공했다. 또한 오프라인 실행과 자동 업데이트 기능을 지원했다.

JavaFX는 2008년에 선보인 리치 인터넷 애플리케이션을 구축하기 위한 현대적인 플랫폼이다. 초기에는 브라우저 플러그인 형태(JavaFX Applet)로 배포되어 애플릿의 후계자를 지향했으나, 이후 독립 실행형 애플리케이션 및 모바일 플랫폼을 위한 기술로 발전했다. JavaFX는 FXML, CSS 스타일링, 하드웨어 가속 그래픽 및 미디어 재생을 지원하여 더 풍부한 사용자 경험을 제공했다.

이 두 기술은 애플릿의 쇠퇴 이후 데스크톱 환경에서 자바 기반의 클라이언트 애플리케이션을 배포하고 실행하는 대안을 제공했다. 그러나 Java Web Start는 2018년 이후 최신 자바 버전에서 공식 지원이 중단되었으며[7], JavaFX는 오라클로부터 분리되어 오픈소스 프로젝트로 계속 발전하고 있다.

HTML5는 자바 애플릿의 주요 대체 기술로 부상했다. HTML5는 웹 표준의 집합체로, 플러그인 없이도 웹 브라우저 내에서 멀티미디어 재생(canvas 요소), 그래픽 렌더링(SVG), 복잡한 애플리케이션 실행을 가능하게 한다. 특히 <canvas> 요소와 WebGL API는 브라우저에서 직접 2D 및 3D 그래픽을 구현할 수 있는 기반을 제공하여, 애플릿이 담당하던 시각적 인터랙션을 대체했다.

JavaScript와 현대적인 웹 API들은 클라이언트 측 로직 실행을 담당한다. 초기의 JavaScript는 단순한 스크립팅 언어에 불과했지만, V8 엔진과 같은 고성능 자바스크립트 엔진의 등장과 Node.js의 발전으로 인해 복잡한 애플리케이션 개발이 가능해졌다. AJAX와 이후의 Fetch API는 서버와의 비동기 통신을 용이하게 하여, 애플릿이 제공하던 풍부한 사용자 경험을 순수 웹 기술로 구현하는 길을 열었다.

WebAssembly(Wasm)는 웹에서 네이티브에 가까운 성능으로 코드를 실행하기 위한 저수준 바이너리 명령어 형식이다. C, C++, Rust와 같은 언어로 작성된 코드를 컴파일하여 브라우저에서 실행할 수 있게 한다. 이는 플러그인 의존성 없이 고성능 계산, 게임, CAD 애플리케이션 등을 웹으로 가져오는 수단을 제공하며, 자바 애플릿이 목표로 했던 "웹에서의 강력한 애플리케이션 실행"이라는 개념을 현대적으로 재해석한 기술이다.

이 세 기술은 상호 보완적으로 작동하며 현대 웹 애플리케이션의 기반을 이룬다. 그 적용 사례를 비교하면 다음과 같다.

결과적으로, HTML5, JavaScript, WebAssembly의 조합은 개방형 웹 표준에 기반하며, 별도의 런타임 설치가 필요 없고 보안 모델이 더 투명하고 통제 가능하다는 점에서 자바 애플릿 아키텍처의 근본적인 한계를 극복했다. 이로 인해 웹은 플러그인 시대를 넘어서 자체적인 강력한 애플리케이션 플랫폼으로 진화하게 되었다.